Languguage OS 2/Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO/gnu/uucp-doc.lha/uucp-doc-1.04/uucp.info-1

GNU Info File | 1993-02-14 | 49KB | 825 lines

This is Info file uucp.info, produced by Makeinfo-1.49 from the input
file uucp.texi.
   This file documents Taylor UUCP, version 1.04.
   Copyright (C) 1992, 1993 Ian Lance Taylor
   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "Copying" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "Copying" may be included in
a translation approved by the author instead of in the original English.
File: uucp.info,  Node: Top,  Next: Copying,  Prev: (dir),  Up: (dir)
Taylor UUCP 1.04
****************
   This is the documentation for the Taylor UUCP package, version 1.04.
The programs were written by Ian Lance Taylor.  The author can be
reached at `<[e-mail]>', or `c/o Cygnus Support, 4th Floor,
Building 200, 1 Kendall Square, Cambridge, MA, 02139'.
   There is a mailing list for discussion of the package.  To join (or
get off) the list, send mail to `<[e-mail]>'.
 Mail to this address is answered by a person, not a program.  When
joining the list, please give the address at which you wish to receive
mail; do not rely on the message headers.  To send a message to the
list, send it to `<[e-mail]>'.
* Menu:
* Copying::                     Taylor UUCP copying conditions
* Introduction::                Introduction to Taylor UUCP
* Overall Installation::        Taylor UUCP installation
* Configuration Files::         Taylor UUCP configuration files
* Protocols::                   UUCP protocol internals
* Hacking::                     Hacking Taylor UUCP
* Acknowledgements::            Acknowledgements
* Index (concepts)::            Concept index
* Index (configuration file)::  Index to new configuration files
 -- The Detailed Node Listing --
Taylor UUCP Overall Installation
* Configuration::               Configuring Taylor UUCP
* Compilation::                 Compiling Taylor UUCP
* Testing::                     Testing Taylor UUCP
* Installation::                Installing Taylor UUCP
* TCP::                         TCP together with Taylor UUCP
Installing Taylor UUCP
* Running uucico::              Running uucico
* Using UUCP for mail and news::  Using UUCP for mail and news.
* Trimming UUCP Log Files::     Trimming UUCP Log Files
Using UUCP for mail and news.
* Sending mail or news::        Sending mail or news via UUCP
* Receiving mail or news::      Receiving mail or news via UUCP
Taylor UUCP Configuration Files
* Configuration File Format::   Configuration file format
* Configuration Examples::      Examples of configuration files
* Time Strings::                How to write time strings
* Chat Scripts::                How to write chat scripts
* config File::                 The main configuration file
* sys File::                    The system configuration file
* port File::                   The port configuration files
* dial File::                   The dialer configuration files
* Security::                    Security issues
Examples of Configuration Files
* config File Examples::        Examples of the main configuration file
* Leaf Example::                Call a single remote site
* Gateway Example::             The gateway for several local systems
The Main Configuration File
* Miscellaneous (config)::      Miscellaneous config file commands
* Configuration File Names::    Using different configuration files
* Log File Names::              Using different log files
* Debugging Levels::            Debugging levels
The System Configuration File
* Defaults and Alternates::     Using defaults and alternates
* Naming the System::           Naming the system
* Calling Out::                 Calling out
* Accepting a Call::            Accepting a call
* Protocol Selection::          Protocol selection
* File Transfer Control::       File transfer control
* Miscellaneous (sys)::         Miscellaneous sys file commands
* Default sys File Values::     Default values
Calling Out
* When to Call::                When to call
* Placing the Call::            Placing the call
* Logging In::                  Logging in
UUCP protocol internals
* Grades::                      UUCP grades
* Lock Files::                  UUCP lock file format
* UUCP Protocol::               The common UUCP protocol
* g Protocol::                  The UUCP `g' protocol
* f Protocol::                  The UUCP `f' protocol
* t Protocol::                  The UUCP `t' protocol
* e Protocol::                  The UUCP `e' protocol
* x Protocol::                  The UUCP `x' protocol
* d Protocol::                  The UUCP `d' protocol
* Capital G Protocol::          The UUCP `G' protocol
* Documentation References::    Documentation references
The Common UUCP Protocol
* Initial Handshake::           Initial handshake
* File Requests::               File requests
* Final Handshake::             Final handshake
File Requests
* S Request::                   S request
* R Request::                   R request
* X Request::                   X request
* H Request::                   H request
Hacking Taylor UUCP
* System Dependence::           System Dependence
* Naming Conventions::          Naming Conventions
* Patches::                     Patches
File: uucp.info,  Node: Copying,  Next: Introduction,  Prev: Top,  Up: Top
Taylor UUCP Copying Conditions
******************************
   This package is covered by the GNU Public License.  See the file
`COPYING' for details.  If you would like to do something with this
package that you feel is reasonable, but you feel is prohibited by the
license, contact me to see if we can work it out.
   Here is some propaganda from the Free Software Foundation.  If you
find this stuff offensive or annoying, remember that you probably did
not spend any money to get this code.  I did not write this code to make
life easier for developers of UUCP packages, I wrote it to help end
users, and I believe that these are the most appropriate conditions for
distribution.
   All the programs, scripts and documents relating to Taylor UUCP are
"free"; this means that everyone is free to use them and free to
redistribute them on a free basis.  The Taylor UUCP-related programs are
not in the public domain; they are copyrighted and there are
restrictions on their distribution, but these restrictions are designed
to permit everything that a good cooperating citizen would want to do.
What is not allowed is to try to prevent others from further sharing any
version of these programs that they might get from you.
   Specifically, we want to make sure that you have the right to give
away copies of the programs that relate to Taylor UUCP, that you receive
source code or else can get it if you want it, that you can change these
programs or use pieces of them in new free programs, and that you know
you can do these things.
   To make sure that everyone has such rights, we have to forbid you to
deprive anyone else of these rights.  For example, if you distribute
copies of the Taylor UUCP related programs, you must give the recipients
all the rights that you have.  You must make sure that they, too,
receive or can get the source code.  And you must tell them their
rights.
   Also, for our own protection, we must make certain that everyone
finds out that there is no warranty for the programs that relate to
Taylor UUCP.  If these programs are modified by someone else and passed
on, we want their recipients to know that what they have is not what we
distributed, so that any problems introduced by others will not reflect
on our reputation.
   The precise conditions of the licenses for the programs currently
being distributed that relate to Taylor UUCP are found in the General
Public Licenses that accompany them.
File: uucp.info,  Node: Introduction,  Next: Overall Installation,  Prev: Copying,  Up: Top
Introduction to Taylor UUCP
***************************
   General introductions to UUCP are available, and perhaps one day I
will write one.  In the meantime, here is a very brief one that
concentrates on the programs provided by Taylor UUCP.
   Taylor UUCP is a complete UUCP package.  It is covered by the GNU
Public License, which means that the source code is always available.
It is composed of several programs; most of the names of these programs
are based on earlier UUCP packages.
`uucp'
     The `uucp' program is used to copy file between systems.  It is
     similar to the standard Unix `cp' program, except that you can
     refer to a file on a remote system by using `system!' before the
     file name.  For example, to copy the file `notes.txt' to the system
     `airs', you would say `uucp notes.txt airs!~/notes.txt'.  In this
     example `~' is used to name the UUCP public directory on `airs'.
`uux'
     The `uux' program is used to request a program to be executed on a
     remote system.  This is how mail and news are transferred over
     UUCP.  As with `uucp', programs and files on remote systems may be
     named by using `system!'.  For example, to run the `rnews' program
     on `airs' passing it standard input, you would say `uux -
     airs!rnews'.  The `-' means to read standard input and set things
     up such that when `rnews' runs on `airs' it will receive the same
     standard input.
   Neither `uucp' nor `uux' actually do any work immediately. Instead,
they queue up requests for later processing.  They then start a daemon
process which processes the requests and calls up the appropriate
systems.  Normally the system will also start the daemon periodically to
check if there is any work to be done.  The advantage of this approach
is that it all happens automatically.  You don't have to sit around
waiting for the files to be transferred.  The disadvantage is that if
anything goes wrong it might be a while before anybody notices.
`uustat'
     The `uustat' program does many things.  By default it will simply
     list all the jobs you have queued with `uucp' or `uux' that have
     not yet been processed.  You can use `uustat' to remove any of
     your jobs from the queue.  You can also it use it to show the
     status of the UUCP system in various ways, such as showing the
     connection status of all the remote systems your system knows
     about.  The system administrator can use `uustat' to automatically
     discard old jobs while sending mail to the user who requested them.
`uuname'
     The `uuname' program by default lists all the remote systems your
     system knows about.  You can also use it to get the name of your
     local system.  It is mostly useful for shell scripts.
`uulog'
     The `uulog' program can be used to display entries in the UUCP log
     file.  It can select the entries for a particular system or a
     particular user.  You can use it to see what has happened to your
     queued jobs in the past.
`uuto'
`uupick'
     `uuto' is a simple shell script interface to `uucp'.  It will
     transfer a file, or the contents of a directory, to a remote
     system, and notify a particular user on the remote system when it
     arrives.  The remote user can then retrieve the file(s) with
     `uupick'.
     The `cu' program can be used to call up another system and
     communicate with it as though you were directly connected.  It can
     also do simple file transfers, though it does not provide any
     error checking.
   These eight programs just described, `uucp', `uux', `uuto',
`uupick', `uustat', `uuname', `uulog', and `cu' are the user programs
provided by Taylor UUCP. `uucp', `uux', and `uuto' add requests to the
work queue, `uupick' extracts files from the UUCP public directory,
`uustat' examines the work queue, `uuname' examines the configuration
files, `uulog' examines the log files, and `cu' just uses the UUCP
configuration files.
   The real work is actually done by two daemon processes, which are
normally run automatically rather than by a user.
`uucico'
     The `uucico' daemon is the program which actually calls the remote
     system and transfers files and requests.  `uucico' is normally
     started automatically by `uucp' and `uux'.  Most systems will also
     start it periodically to make sure that all work requests are
     handled.  `uucico' checks the queue to see what work needs to be
     done, and then calls the appropriate systems.  If the call fails,
     perhaps because the phone line is busy, `uucico' leaves the
     requests in the queue and goes on to the next system to call.  It
     is also possible to force `uucico' to call a remote system even if
     there is no work to be done for it, so that it can pick up any
     work that may be queued up remotely.
`uuxqt'
     The `uuxqt' daemon processes execution requests made by the `uux'
     program on remote systems.  It also processes requests made on the
     local system which require files from a remote system.  It is
     normally started by `uucico'.
   Suppose you, on the system `bantam', want to copy a file to the
system `airs'.  You would run the `uucp' command locally, with a
command like `uucp notes.txt airs!~/notes.txt'.  This would queue up a
request on `bantam' for `airs', and would then start the `uucico'
daemon.  `uucico' would see that there was a request for `airs' and
attempt to call it.  When the call succeeded, another copy of `uucico'
would be started on `airs'.  The two copies of `uucico' would tell each
other what they had to do and transfer the file from `bantam' to
`airs'.  When the file transfer was complete the `uucico' on `airs'
would move it into the UUCP public directory.
   UUCP is often used to transfer mail.  This is normally done
automatically by mailer programs.  When `bantam' has a mail message to
send to `ian' at `airs', it executes `uux - airs!rmail ian' and writes
the mail message to the `uux' process as standard input.  The `uux'
program, running on `bantam', will read the standard input and store
it, as well as the `rmail' request itself, on the work queue for
`airs'.  `uux' will then start the `uucico' daemon.  The `uucico'
daemon will call up `airs', just as in the `uucp' example, and transfer
the work request and the mail message.  The `uucico' daemon on `airs'
will put the files on a local work queue.  When the communication
session is over, the `uucico' daemon on `airs' will start the `uuxqt'
daemon.  `uuxqt' will see the request to run, and will run `rmail ian'
with the mail message as standard input.  The `rmail' program, which is
not part of the UUCP package, is then responsible for either putting
the message in the right mailbox on `airs' or forwarding the message on
to another system.
   Taylor UUCP comes with a few other programs that are useful when
installing and configuring UUCP.
`uuchk'
     The `uuchk' program reads the UUCP configuration files and displays
     a rather lengthy description of what it finds.  This is useful when
     configuring UUCP to make certain that the UUCP package will do
     what you expect it to do.
`uuconv'
     The `uuconv' program can be used to convert UUCP configuration
     files from one support format to another.  This can be useful for
     administrators converting from an older UUCP.  Taylor UUCP is able
     to read and use old configuration file formats, but some new
     features can not be selected using the old formats.
`uusched'
     The `uusched' script is just provided for compatibility with older
     UUCP releases.  It starts `uucico' to call, one at a time, all the
     systems for which work has been queued.
`tstuu'
     The `tstuu' program is a test harness for the UUCP package, which
     will help ensure that it has been configured and compiled
     correctly.  It does not test everything, however.  It only runs on
     Unix systems which support Berkeley style pseudo-terminals or
     STREAMS style pseudo-terminals.  It can be useful when initially
     installing Taylor UUCP.
File: uucp.info,  Node: Overall Installation,  Next: Configuration Files,  Prev: Introduction,  Up: Top
Taylor UUCP Overall Installation
********************************
   These are the installation instructions for the Taylor UUCP package.
* Menu:
* Configuration::               Configuring Taylor UUCP
* Compilation::                 Compiling Taylor UUCP
* Testing::                     Testing Taylor UUCP
* Installation::                Installing Taylor UUCP
* TCP::                         TCP together with Taylor UUCP
File: uucp.info,  Node: Configuration,  Next: Compilation,  Prev: Overall Installation,  Up: Overall Installation
Configuring Taylor UUCP
=======================
   You will have to decide what types of configuration files you want to
use.  This package supports a new sort of configuration file; see *Note
Configuration Files::.  It also supports V2 configuration files
(`L.sys', `L-devices', etc.) and HDB configuration files (`Systems',
`Devices', etc.).  No documentation is provided for V2 or HDB
configuration files.  All types of configuration files can be used at
once, if you are so inclined.  Currently using just V2 configuration
files is not really possible, because there is no way to specify a
dialer (there are no built in dialers, and the program does not know
how to read `acucap' or `modemcap'); however, V2 configuration files
can be used with a new style dialer file (*note dial File::.), or with
a HDB `Dialers' file.
   Use of HDB configuration files has two known bugs.  A blank line in
the middle of an entry in the `Permissions' file will not be ignored as
it should be.  Dialer programs, as found in some versions of HDB, are
not recognized directly.  If you must use a dialer program, rather than
an entry in `Devices', you must use the `chat-program' command in a new
style dialer file; see *Note dial File::.  You will have to invoke the
dialer program via a shell script, since an exit code of 0 is required
to recognize success.
   The `uuconv' program can be used to convert from V2 or HDB
configuration files to the new style (it can also do the reverse
translation, if you are so inclined).  It will not do all of the work,
and the results should be carefully checked, but it can be quite useful.
   If you are installing a new system, you will, of course, have to
write the configuration files; see *Note Configuration Files::.
   You must also decide what sort of spool directory you want to use.
If you will only be using these programs, I recommend
`SPOOLDIR_TAYLOR'; otherwise select the spool directory corresponding
to your existing UUCP package.  The details of the spool directory
choices are described at somewhat tedious length in `unix/spool.c'.
File: uucp.info,  Node: Compilation,  Next: Testing,  Prev: Configuration,  Up: Overall Installation
Compiling Taylor UUCP
=====================
  1. Take a look at the top of `Makefile.in' and set the appropriate
     values for your system.  These control where the programs are
     installed and which user on the system owns them (normally they
     will be owned by a special user `uucp' rather than a real person;
     they should probably not be owned by `root').
  2. Run the shell script `configure'.  This script was generated using
     the `autoconf' program written by David MacKenzie of the Free
     Software Foundation.  It takes a while to run.  It will generate
     the file `conf.h' based on `conf.h.in', and, for each source code
     directory, will generate `Makefile' based on `Makefile.in'.
     You can pass certain arguments to `configure' in the environment.
     Because `configure' will compile little test programs to see what
     is available on your system, you must tell it how to run your
     compiler. It recognizes the following environment variables:
    `CC'
          The C compiler.  If this is not set, then if `configure' can
          find `gcc' it will use it, otherwise it will use `cc'.
    `CFLAGS'
          Flags to pass to the C compiler when compiling the actual
          code.  If this is not set, `configure' will use `-g'.
    `LDFLAGS'
          Flags to pass to the C compiler when only linking, not
          compiling.  If this is not set, `configure' will use the
          empty string.
    `LIBS'
          Libraries to pass to the C compiler.  If this is not set,
          `configure' will use the empty string.
    `INSTALL'
          The program to run to install UUCP in the binary directory.
          If this is not set, then if `configure' finds the BSD
          `install' program, it will set this to `install -c';
          otherwise, it will use `cp'.
    `INSTALLDATA'
          The program to run to install UUCP data files, such as the
          man pages and the info pages.  If this is not set, then if
          `configure' finds the BSD `install' program, it will set this
          to `install -c -m 644'; otherwise, it will use `cp'.
     Suppose you want to set the environment variable `CC' to `rcc'.
     If you are using `sh' or `bash', invoke `configure' as `CC=rcc
     configure'.  If you are using `csh', do `setenv CC rcc; sh
     configure'.
     On some systems you will want to use `LIBS=-lmalloc'.  On Xenix
     derived versions of Unix do not use `LIBS=-lx' because this will
     bring in the wrong versions of certain routines; if you want to use
     `-lx' you must specify `LIBS=-lc -lx'.
     If `configure' fails for some reason, or if you have a very wierd
     system, you may have to configure the package by hand.  To do
     this, copy the file `conf.h.in' to `conf.h' and edit it for your
     system. Then for each source directory (the top directory, and the
     subdirectories `lib', `unix', and `uuconf') copy `Makefile.in' to
     `Makefile', find the words within `@' characters, and set them
     correctly for your system.
  3. Igor V. Semenyuk provided this (lightly edited) note about ISC
     Unix 3.0. The `configure' script will default to passing `-posix'
     to `gcc'.  However, using `-posix' changes the environment to
     POSIX, and on ISC 3.0, at least, the default for POSIX_NO_TRUNC is
     1. This means nothing for uucp, but can lead to a problem when
     uuxqt executes rmail.  IDA sendmail has dbm configuration files
     named `mailertable.{dir,pag}'.  Notice these names are 15
     characters long.  When uuxqt compiled with `-posix' executes
     rmail, which in turn executes sendmail, the later is run under
     POSIX environment too! This leads to sendmail bombing out with
     `'error opening 'M' database: name too long' (mailertable.dir)'.
     It's rather obscure behaviour, and it took me a day to find out
     the cause.  I don't use `-posix', instead I run `gcc' with
     `-D_POSIX_SOURCE', and add `-lcposix' to `LIBS'.
  4. You should verify that `configure' worked correctly by checking
     `conf.h' and the instances of `Makefile'.
  5. Edit `policy.h' for your local system.  The comments should explain
     the various choices.  The default values are intended to be
     reasonable, so you may not have to make any changes.
  6. Type `make' to compile everything.  The `tstuu.c' file is not
     particularly portable; if you can't figure out how to compile it
     you can safely ignore it, as it is only used for testing (to use
     STREAMS pseudo-terminals, tstuu.c must be compiled with
     `-DHAVE_STREAMS_PTYS'; this is not automatically determined at the
     moment).  If you have any other problems there is probably a bug
     in the `configure' script.
  7. Please report any problems you have.  That is the only way they
     will get fixed for other people.  Supply a patch if you can (*note
     Patches::.), or just ask for help.
File: uucp.info,  Node: Testing,  Next: Installation,  Prev: Compilation,  Up: Overall Installation
Testing Taylor UUCP
===================
   This package is in use at many sites, and has been running at
`airs.com' for over a year.  However, it will doubtless fail in some
situations.  Do not rely on this code until you have proven to yourself
that it will work.
   You can use the `uuchk' program to test your configuration files. It
will read them and print out a verbose description.  This program
should not be made setuid, because it will display passwords if it can
read them.
   If your system supports pseudo-terminals, and you compiled the code
to support the new style of configuration files, you should be able to
use the `tstuu' program to test the `uucico' daemon (if your system
supports STREAMS based pseudo-terminals, you must compile tstuu.c with
`-DHAVE_STREAMS_PTYS', at least at the moment; the STREAMS based code
was contributed by Marc Boucher).
   To run `tstuu', just type `tstuu' with no arguments while logged in
to the compilation directory (since it runs `./uucp', `./uux' and
`./uucico').  It will run a lengthy series of tests (it takes over ten
minutes on a slow VAX).  You will need a fair amount of space available
in `/usr/tmp'.  You will probably want to put it in the background.  Do
not use `^Z', because the program traps on `SIGCHLD' and winds up
dying.  It will create a directory `/usr/tmp/tstuu' and fill it with
configuration files, and create spool directories
`/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'.
   If your system does not support the `FIONREAD' call, the `tstuu'
program will run very slowly.  This may or may not get fixed in a later
version.
   The `tstuu' program does not seem to work under SunOS 4.1.1.  This
seems to be due to a bug in the implementation of ptys.
   The program will finish with an execute file named `X.SOMETHING' and
a data file named `D.SOMETHING' in the directory
`/usr/tmp/tstuu/spool1' (or, more likely, in subdirectories, depending
on the choice of `SPOOLDIR' in `policy.h').  Two log files will be
created in the directory `/usr/tmp/tstuu'.  They will be named `Log1'
and `Log2', or, if you have selected `HAVE_HDB_LOGGING' in `policy.h',
`Log1/uucico/test2' and `Log2/uucico/test1'.  You can test `uuxqt' by
running the command `./uuxqt -I /usr/tmp/tstuu/Config1'.  This should
leave a command file `C.SOMETHING' and a data file `D.SOMETHING' in
`/usr/tmp/tstuu/spool1' or in subdirectories.  Again, there should be
no errors in the log file.
   Assuming you compiled the code with debugging enabled, the `-x'
switch can be used to set debugging modes; see the `debug' command for
details (*note Debugging Levels::.).  Use `-x all' to turn on all
debugging and generate far more output than you will ever want to see.
The `uucico' daemons will put debugging output in the files `Debug1'
and `Debug2' in the directory `/usr/tmp/tstuu'. After that, you're
pretty much on your own.
   On some systems you can also use `tstuu' to test `uucico' against
the system `uucico', by using the `-u' switch.  For this to work,
change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at the top
of `tstuu.c' to something appropriate for your system.  The definitions
in `tstuu.c' are what I used for Ultrix 4.0, on which
`/usr/lib/uucp/uucico' is particularly obstinate about being run as a
child; I was only able to run it by creating a login name with no
password whose shell was `/usr/lib/uucp/uucico'.  Calling login in this
way will leave fake entries in `wtmp' and `utmp'; if you compile
`tstout.c' (in the `contrib' directory) as a setuid `root' program,
`tstuu' will run it to clear those entries out.  On most systems, such
hackery should not be necessary, although on SCO I had to su to `root'
(`uucp' might also have worked) before I could run
`/usr/lib/uucp/uucico'.
   You can test `uucp' and `uux' (give them the `-r' switch to keep
them from starting `uucico') to make sure they create the right sorts
of files.  Unfortunately, if you don't know what the right sorts of
files are, I'm not going to tell you here.
   If `tstuu' passes, or you can't run it for some reason or other,
move on to testing with some other system.  Set up the configuration
files (*note Configuration Files::.), or use an existing configuration.
Tell `uucico' to dial out to the system by using the `-s' system switch
(e.g.  `uucico -s uunet').  The log file should tell you what happens.
   If you compiled the code with debugging enabled, you can use
debugging mode to get a great deal of information about what sort of
data is flowing back and forth; the various possibilities are described
under the `debug' command (*note Debugging Levels::.).  When initially
setting up a connection `-x chat' is probably the most useful (e.g.
`uucico -s uunet -x chat'); you may also want to use `-x
handshake,incoming,outgoing'.  You can use `-x' multiple times on one
command line, or you can give it comma separated arguments as in the
last example.  Use `-x all' to turn on all possible debugging
information.  The debugging information is written to a file, normally
`/usr/spool/uucp/Debug', although the default can be changed in
`policy.h' and the configuration file can override the name with the
`debugfile' command.  The debugging file may contain passwords and some
file contents as they are transmitted over the line, so the debugging
file is only readable by the `uucp' user.
   You can use the `-f' switch to force `uucico' to call out even if
the last call failed recently; using `-S' when naming a system has the
same effect.  Otherwise the status file (in the `.Status' subdirectory
of the main spool directory, normally `/usr/spool/uucp') will prevent
too many attempts from occurring in rapid succession.
   Again, please let me know about any problems you have and how you got
around them.  If you do report a problem, please include the version
number of the package you are using, and a sample of the debugging file
showing the problem.  General questions such as "why doesn't uucico
dial out" are impossible to answer without much more information.
File: uucp.info,  Node: Installation,  Next: TCP,  Prev: Testing,  Up: Overall Installation
Installing Taylor UUCP
======================
   You can install the executable files by becoming `root' and typing
`make install'.  Or you can look at what `make install' does and do it
by hand.  It tries to preserve your old programs, if any, but it only
does this the first time Taylor UUCP is installed (so that if you
install several versions of Taylor UUCP, you can still go back to your
original UUCP programs).  You can retrieve the original programs by
typing `make uninstall'.
   Simply installing the executable files is not enough, however.  You
must also arrange for them to be used correctly.
* Menu:
* Running uucico::              Running uucico
* Using UUCP for mail and news::  Using UUCP for mail and news.
* Trimming UUCP Log Files::     Trimming UUCP Log Files
File: uucp.info,  Node: Running uucico,  Next: Using UUCP for mail and news,  Prev: Installation,  Up: Installation
Running uucico
--------------
   By default `uucp' and `uux' will automatically start up `uucico' to
call another system whenever work is queued up. However, the call may
fail, or there may be time restrictions which prevent the call at that
time (perhaps because telephone rates are high) (*note When to
Call::.).  Also, a remote system may have work queued up for your
system, but may not be calling you for some reason (perhaps you have
agreed that your system should always place the call).  To make sure
that works get transferred between the systems withing a reasonable
time period, you should arrange to periodically invoke `uucico'.
   These periodic invocations are normally caused by entries in the
`crontab' file.  The exact format of `crontab' files, and how new
entries are added, varies from system to system; check your local
documentation (try `man cron').
   To attempt to call all systems with outstanding work, use the command
`uucico -r1'.  To attempt to call a particular system, use the command
`uucico -s SYSTEM'.
   A common case is to want to try to call a system at a certain time,
with periodic retries if the call fails.  A simple way to do this is to
create an UUCP command file, known as a "poll file".  If a poll file
exists for a system, then `uucico -r1' will place a call to it.  If the
call succeeds, the poll file will be deleted.
   The file can be easily created using the `touch' command.  The name
of a poll file currently depends on the type of spool directory you are
using, as set in `policy.h'.  If you are using `SPOOLDIR_TAYLOR' (the
default), put something like this in your `crontab' file:
     touch /usr/spool/uucp/SYS/C./C.A0000
   In this example SYS is the system you wish to call, and
`/usr/spool/uucp' is your UUCP spool directory. If you are using
`SPOOLDIR_HDB', use
     touch /usr/spool/uucp/SYS/C.SYSA0000
   For example, I use the following crontab entries locally:
     45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa
     40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000
   Every hour, at 45 minutes past, this will check if there is any work
to be done, and, if there is, will call the appropriate system.  Also,
at 4:40am, 10:40am and 3:40pm this will create a poll file file for
`uunet', forcing the next check to call `uunet'.
File: uucp.info,  Node: Using UUCP for mail and news,  Next: Trimming UUCP Log Files,  Prev: Running uucico,  Up: Installation
Using UUCP for mail and news.
-----------------------------
   Taylor UUCP does not include a mail package.  All Unix systems come
with some sort of mail delivery agent, typically `sendmail' or `MMDF'.
Source code is available for some mail delivery agents, such as `IDA
sendmail' and `smail'.
   Taylor UUCP also does not include a news package.  The two major Unix
news packages are `C-news' and `INN'.  Both are available in source
code form.
   Configuring and using mail delivery agents is a notoriously complex
topic, and I will not be discussing it here.  Configuring news systems
is usually simpler, but I will not be discussing that either.  I will
merely describe the interactions between the mail and news systems and
UUCP.
   A mail or news system interacts with UUCP in two ways.
* Menu:
* Sending mail or news::        Sending mail or news via UUCP
* Receiving mail or news::      Receiving mail or news via UUCP
File: uucp.info,  Node: Sending mail or news,  Next: Receiving mail or news,  Prev: Using UUCP for mail and news,  Up: Using UUCP for mail and news
Sending mail or news via UUCP
.............................
   When mail is to be sent from your machine to another machine via
UUCP, the mail delivery agent will invoke `uux'.  It will generally run
a command such as `uux - SYSTEM!rmail', where SYSTEM is the remote
system to which the mail is being sent.  It may pass other options to
`uux', such as `-r' or `-g'.
   News also invokes `uux' in order to transfer articles to another
system.  The only difference is that news will use `uux' to invoke
`rnews' on the remote system, rather than `rmail'.
   You should arrange for your mail and news systems to invoke the
Taylor UUCP version of `uux' when sending mail via UUCP.  If you simply
replace any existing version of `uux' with the Taylor UUCP version,
this will probably happen automatically.  However, if both versions
exist on your system, you will probably have to modify the mail and news
configuration files in some way.
   Actually, if both the system UUCP and Taylor UUCP are using the same
spool directory format, the system `uux' will probably work fine with
the Taylor `uucico' (the reverse is not the case: the Taylor `uux'
requires the Taylor `uucico').  However, data transfer will be somewhat
more efficient if the Taylor `uux' is used.
File: uucp.info,  Node: Receiving mail or news,  Prev: Sending mail or news,  Up: Using UUCP for mail and news
Receiving mail or news via UUCP
...............................
   As noted in *Note Sending mail or news::, mail is sent by requesting
a remote execution of `rmail'.  To receive mail, then, all that is
necessary is for UUCP to invoke `rmail' itself.
   Any mail delivery agent will provide an appropriate version of
`rmail'; you must simply make sure that it is in the command path used
by UUCP (it almost certainly already is).  The default command path is
set in `policy.h', and it may be overridden for a particular system by
the `command-path' command (*note Miscellaneous (sys)::.).
   Similarly, for news UUCP must be able to invoke `rnews'.  Any news
system will provide a version of `rnews', and you must ensure that is
in a directory on the path that UUCP will search.
File: uucp.info,  Node: Trimming UUCP Log Files,  Prev: Using UUCP for mail and news,  Up: Installation
Trimming UUCP Log Files
-----------------------
   You should also periodically trim the log files, as they will
otherwise continue to grow without limit.  The names of the log files
are set in `policy.h', and may be overridden in the configuration file
(*note config File::.).  By default they are are `/usr/spool/uucp/Log'
and `/usr/spool/uucp/Stats'.
   You may find the `savelog' program in the `contrib' directory may be
of use.  There is a manual page for it in `contrib' as well.
File: uucp.info,  Node: TCP,  Prev: Installation,  Up: Overall Installation
TCP together with Taylor UUCP
=============================
   If your system has a Berkeley style socket library, or a System V
style TLI interface library, you can compile the code to permit making
connections over TCP.  Specifying that a system should be reached via
TCP is easy, but nonobvious.
   If you are using the new style configuration files, see *Note
Configuration Files::.  Basically, you can just add the line `port type
tcp' to the entry in the system configuration file.  By default UUCP
will get the port number by looking up `uucp' in `/etc/services'; if
`uucp' is not found, port 540 will be used.  You can set the port
number to use with the command `port service XXX', where XXX can be
either a number or a name to look up in `/etc/services'.  You can
specify the address of the remote host with `address A.B.C'; if you
don't give an address, the remote system name will be used.  You should
give an explicit chat script for the system when you use TCP; the
default chat script begins with a carriage return, which will not work
with some UUCP TCP servers.
   If you are using V2 configuration files, add a line like this to
`L.sys':
     SYS Any TCP uucp HOST.DOMAIN chat-script
   This will make an entry for system SYS, to be called at any time,
over TCP, using port number `uucp' (as found in `/etc/services'; this
may be specified as a number), using remote host `HOST.DOMAIN', with
some chat script.
   If you are using HDB configuration files, add a line like this to
Systems:
     SYS Any TCP - HOST.DOMAIN chat-script
   and a line like this to Devices:
     TCP uucp - -
   You only need one line in Devices regardless of how many systems you
contact over TCP.  This will make an entry for system SYS, to be called
at any time, over TCP, using port number `uucp' (as found in
`/etc/services'; this may be specified as a number), using remote host
`HOST.DOMAIN', with some chat script.
   The `uucico' daemon can also be run as a TCP server.  To use the
default port number, which is a reserved port, `uucico' must be invoked
by root (or it must be set user ID to root, but I don't recommend doing
that).
   Basically, you must define a port, either using the port file (*note
port File::.) if you are using the new configuration method or with an
entry in Devices if you are using HDB; there is no way to define a port
using V2.  If you are using HDB the port must be named `TCP'; a line as
shown above will suffice.  You can then start `uucico' as `uucico -p
TCP' (after the `-p', name the port; in HDB it must be `TCP').  This
will wait for incoming connections, and fork off a child for each one.
Each connection will be prompted with `login:' and `Password:'; the
results will be checked against the UUCP (not the system) password file
(*note Configuration File Names::.).
   Of course, you can get a similar effect by using the BSD `uucpd'
program.
   You can also have `inetd' start up `uucico' with the `-l' switch,
which will cause it to prompt with `login:' and `Password:' and check
the results against the UUCP (not the system) password file.  This may
be used in place of `uucpd'.
File: uucp.info,  Node: Configuration Files,  Next: Protocols,  Prev: Overall Installation,  Up: Top
Taylor UUCP Configuration Files
*******************************
   This chapter describes the configuration files accepted by the Taylor
UUCP package if compiled with `HAVE_TAYLOR_CONFIG' defined in
`policy.h'.
   The configuration files are normally found in the directory
NEWCONFIGDIR, which is defined by the `Makefile' variable
`newconfigdir'; by default NEWCONFIGDIR is `/usr/local/conf/uucp'.
However, the main configuration file, `config', is the only one which
must be in that directory, since it may specify a different location
for any or all of the other files.  You may run any of the UUCP
programs with a different main configuration file by using the `-I'
option; this can be useful when testing a new configuration.  When you
use the `-I' option the programs will revoke any setuid privileges.
* Menu:
* Configuration File Format::   Configuration file format
* Configuration Examples::      Examples of configuration files
* Time Strings::                How to write time strings
* Chat Scripts::                How to write chat scripts
* config File::                 The main configuration file
* sys File::                    The system configuration file
* port File::                   The port configuration files
* dial File::                   The dialer configuration files
* Security::                    Security issues
File: uucp.info,  Node: Configuration File Format,  Next: Configuration Examples,  Prev: Configuration Files,  Up: Configuration Files
Configuration File Format
=========================
   All the configuration files follow a simple line-oriented `KEYWORD
VALUE' format.  Empty lines are ignored, as are leading spaces; unlike
HDB, lines with leading spaces are read.  The first word on each line
is a keyword.  The rest of the line is interpreted according to the
keyword.  Most keywords are followed by numbers, boolean values or
simple strings with no embedded spaces.
   The `#' character is used for comments.  Everything from a `#' to
the end of the line is ignored unless the `#' is preceded by a `\'
(backslash); if the `#' is preceeded by a `\', the `\' is removed but
the `#' remains in the line.  This can be useful for a phone number
containing a `#'.  To enter the sequence `\#', use `\\#'.
   The backslash character may be used to continue lines.  If the last
character in a line is a backslash, the backslash is removed and the
line is continued by the next line.  The second line is attached to the
first with no intervening characters; if you want any whitespace between
the end of the first line and the start of the second line, you must
insert it yourself.
   However, the backslash is not a general quoting character.  For
example, you cannot use it to get an embedded space in a string
argument.
   Everything after the keyword must be on the same line.  A BOOLEAN
may be specified as `y', `Y', `t', or `T' for true and `n', `N', `f',
or `F' for false; any trailing characters are ignored, so `true',
`false', etc., are also acceptable.
File: uucp.info,  Node: Configuration Examples,  Next: Time Strings,  Prev: Configuration File Format,  Up: Configuration Files
Examples of Configuration Files
===============================
   All the configuration commands are explained in the following
sections. However, I'll start by giving a few examples of configuration
files. For a more complete description of any of the commands used here
see the appropriate section of this chapter.  There are also sample
configuration files in the `sample' subdirectory of the distribution.
* Menu:
* config File Examples::        Examples of the main configuration file
* Leaf Example::                Call a single remote site
* Gateway Example::             The gateway for several local systems
File: uucp.info,  Node: config File Examples,  Next: Leaf Example,  Prev: Configuration Examples,  Up: Configuration Examples
config File Examples
--------------------
   To start with, here are some examples of uses of the main
configuration file, `config'.  For a complete description of the
commands that are permitted in `config', see *Note config File::.
   In many cases you will not need to create a `config' file at all.
The most common reason to create one is to give your machine a special
UUCP name.  Other reasons might be to change the UUCP spool directory or
to permit any remote system to call in.
   If you have an internal network of machines, then it is likely that
the internal name of your UUCP machine is not the name you want to use
when calling other systems.  For example, here at `airs.com' our
mail/news gateway machine is named `elmer.airs.com' (it is one of
several machines all named `LOCALNAME.airs.com').  If we did not
provide a `config' file, then our UUCP name would be `elmer'; however,
we actually want it to be `airs'. Therefore, we use the following line
in `config':
     nodename airs
   The UUCP spool directory name is set in `policy.h' when the code is
compiled.  You might at some point decide that it is appropriate to move
the spool directory, perhaps to put it on a different disk partition.
You would use the following commands in `config' to change to
directories on the partition `/uucp':
     spool /uucp/spool
     pubdir /uucp/uucppublic
     logfile /uucp/spool/Log
     debugfile /uucp/spool/Debug
   You would then move the contents of the current spool directory to
`/uucp/spool'.  If you do this, make sure that no UUCP processes are
running while you change `config' and move the spool directory.
   Suppose you wanted to permit any system to call in to your system and
request files.  This is generally known as "anonymous UUCP", since the
systems which call in are effectively anonymous.  By default, unknown
systems are not permitted to call in.  To permit this you must use the
`unknown' command in `config'.  The `unknown' command is followed by
any command that may appear in the system file; for full details, see
*Note sys File::.
   I will show two possible anonymous UUCP configurations.  The first
will let any system call in and download files, but will not permit
them to upload files to your system.
     # No files may be transferred to this system
     unknown receive-request no
     # The public directory is /usr/spool/anonymous
     unknown pubdir /usr/spool/anonymous
     # Only files in the public directory may be sent (the default anyhow)
     unknown remote-send ~
Setting the public directory is convenient for the systems which call
in.  It permits to request a file by prefixing it with `~/'.  For
example, assuming your system is known as `server', then to retrieve
the file `/usr/spool/anonymous/INDEX' a user on a remote site could
just enter `uucp server!~/INDEX ~'; this would transfer `INDEX' from
`server''s public directory to the user's local public directory.  Note
that when using `csh' or `bash' the `!' and the second `~' must be
quoted.
   The next example will permit remote systems to upload files to a
special directory named `/usr/spool/anonymous/upload'.  Permitting a
remote system to upload files permits it to send work requests as well;
this example is careful to prohibit commands from unknown systems.
     # No commands may be executed (the list of permitted commands is empty)
     unknown commands
     # The public directory is /usr/spool/anonymous
     unknown pubdir /usr/spool/anonymous
     # Only files in the public directory may be sent; users may not download
     # files from the upload directory
     unknown remote-send ~ !~/upload
     # May only upload files into /usr/spool/anonymous/upload
     unknown remote-receive ~/upload